✅ Deploy Preview for endearing-brigadeiros-63f9d0 canceled.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 77.59%. Comparing base (6bdf166) to head (d911c3e).

@@            Coverage Diff             @@
##             main    #1109      +/-   ##
==========================================
- Coverage   79.62%   77.59%   -2.04%     
==========================================
  Files          59       61       +2     
  Lines        2479     2571      +92     
  Branches      289      301      +12     
==========================================
+ Hits         1974     1995      +21     
- Misses        461      532      +71     
  Partials       44       44              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I could do with some clarification of why the repository name didn't exactly match. Until #1043 is merged, git-proxy can't support multiple forks of the same repo (project or organisation name is different, repo name the same). This PR addresses one or two of those but, by including only a subset of the changes from #1043 it doesn't give you the ability work with multiple forks through the API or UI.

The discrepancy here is due to testing against GitLab, which allows arbitrary display names for repos. For example, I have a repo named Git Proxy Infra, but the actual repo URL in the git push is git-proxy-infra. So the display name and the slug used in the push don't exactly match — which causes issues with how git-proxy currently resolves repositories. People tend to enter the name they see in the UI.

@andypols That makes sense. I believe that in #1043 we entirely remove the user of the repoName across the proxy, API and UI, other than for display purposes (as you do here in just the proxy using the same approach and some of the same code - but with more work on the tests).

TBH I thought about remove the project/user fields entirely as we retrieve the same info from the Github and Gitlab APIs... I was stalled in the end by the idea that you would want a manually entered one for standalone git repos or other SCM hosts we don't have a specific integration for + the fact someone could be relying on them in a plugin implementation. The project (organisation) field is easier to remove as thats a github/gitlab concept (and differs between them as Gitlab supports many levels of sub-orgs), which could come from the respective APIs (the field is returned but we don't currently need it, instead we just extract the URL to it in utils.tsx / fetchRemoteRepositoryData)

@kriswest I agree about removing the project/name fields when adding a repository. All you need is the clone URL

@andypols is any part of this PR NOT included in #1043 that I should be considering adding to it?

@kriswest no - I did to address this one issue and unblock our security team

@finos/git-proxy-maintainers @andypols and I have been chatting off to the side and essentially we have the same goal, we need these fixes to go in ASAP. He's raised this PR and #1110 in the hopes of speeding up resolution / adoption of some of the changes (+some work to improve the approach to building tests, particularly of the DB clients).

If #973 and #1043 go in soon, then we only need the test additions from these PRs and and I'll work (with @andypols) on getting them in. If there is likely to be an delay then #1109 and #1110 should be prioritised (and i'll have to maintain the others further). My preference is obviously for the former option to happen ASAP - but I don't want to unduly block another adopter if we can't get them merged ASAP.

@jescalada I'm conscious that I haven't looked at your PRs yet, but am happy to help in anyway that gets us to the end goal here ;-)

@kriswest We're waiting for a FINOS admin to help us unblock the PRs we talked about in the call. Maintainers cannot actually merge them directly through GitHub so we would need extended permissions or coordinate with an admin to get them in...

If it's not too much of a hassle to keep maintaining your PRs, I can take a look at #1109, #1110 and the other fix PRs by @andypols and make a patch release so their org can keep pentesting smoothly (which I believe is valuable to all of us).

As for my PRs, a quick look would be appreciated but they are pretty much ready to merge barring the permissions issue 🙂

I agree about removing the project/name fields when adding a repository. All you need is the clone URL

Seconding this for adding repos - it's simple and reliable. We can prepopulate the other values (repo name, organization, etc.) after fetching from the repo URL.

@jescalada – thanks for the test suggestions; I've added them. The one testing unknown URLs in mongo didn’t work at this level, though, since the unit test only checks queries against a mocked database. I’ve removed that one.